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SHARPS  model.  Inquiries  of  this  nature  require  prompt  action  and  a  timely 
status  report  to  all  concerned  parties.  A  more  expeditious  NORDA  response 
Is  possible  when  consistency  Is  maintained  between  the  FNOC  and  NORDA 
versions  of  the  model. 

2.4  DOCUMENTATION 

Section  4.0  of  this  report  contains  a  description  of  the  SHARPS 
documentation  required  by  the  NORDA  configuration  management  program. 

Thorough  documentation  of  the  SHARPS  model  Is  one  of  the  most  Important 
steps  In  assuring  the  credibility  of  the  model,  and  serves  numerous 
functions  Including  the  following: 

•  description  of  model  physics 

•  description  of  model  software 

•  provides  Fleet  user  with  a  description  of  the  product 

•  provides  R4D  user  with  a  thorough  model  description 

•  provides  good  starting  point  for  problem  analysis 

3.0  ORGANIZATIONAL  RESPONSIBILITIES 

Figure  (1)  provides  an  overview  of  the  organizational  responsibilities 
involved  In  configuration  management  of  the  SHARPS  model. 

3.1  NAVAL  OCEAN  RESEARCH  AND  DEVELOPMENT  ACTIVITY  (NORDA) 

NORDA  provides  funding  for  and  maintains  executive  control  over  the 
configuration  management  of  the  SHARPS  model.  In  addition,  NORDA  provides 


Figure  1.  SHARPS  Configuration  Management  Organizational  Re^ransibilities 
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should  bo  Insortod  In  place  of  the  deleted  code.  These 
COMMENT  cards  should  state  that  system  dependent  code  has 
been  replaced. 

e  If  $y stem  dependent  code  Is  to  be  replaced  by  other  code, 
comments  to  this  effect  must  precede  the  new  code. 

The  update  I0ENT  for  the  set  of  system  dependent  updates  will  be 
NORDA.  This  will  permit  a  programmer  to  scan  the  code  for  a 
particular  routine  or  set  of  routines  and  easily  Identify  the 
NORDA  only  code.  The  resultant  PL  will  be  catalogued  as 
SHARP SNQRDAPl  and  the  corresponding  binary  file  of  executable 
code  (LGO)  as  SHARPSNORDALGO.  The  cycle  number  will  be  the  same 
as  that  used  for  SHARPSFNOCPL. 

5.1.4  The  model  will  then  be  executed  at  NORDA  and  at  FNOC  using 
duplicate  Input  data  sets,  and  output  from  the  NORDA  version 
will  be  compared  to  output  from  the  FNOC  operational  version. 

If  any  Inconsistencies  are  found,  they  will  be  resolved  before 
continuing. 

5.2  UPDATE  INITIATION 

5.2.1  Each  proposed  SHARPS  update  set  not  directly  prepared  by  the 
principal  software  analyst  Is  to  be  delivered  to  him  via  an 
appropriate  medium  (e.g.,  tape,  disk  file,  cards,  listing)  as 
the  first  step  In  the  SHARPS  update  cycle. 
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5.2.2  The  update  set  will  be  assigned  a  SHARPS  update  number  (SUN) 
consisting  of  three  decimal  digits  followed  by  the  letter  A 
(e.g.,  013A).  The  first  update  set  will  be  001A  and  each 
subsequent  new  update  set  will  have  a  SUN  that  Increases  by  one 
(l.e.,  002A,  003A,  etc.).  However,  If  modification  Is  made  to 
an  existing  update  set,  the  resultant  update  set  will  be 
assigned  a  SUN  whose  alphabetic  element  Is  the  next  unused 
letter  In  the  alphabet.  For  example.  If  update  set  002A  Is 
modified  for  the  first  time,  the  resultant  update  set  will  have 
a  SUN  of  002B.  Then,  If  either  002A  or  002B  Is  subsequently 

modified,  the  new  update  set  will  be  002C.  Thus,  each  update 
set  will  have  a  unique  SUN  that  will  be  associated  with  that 
update  set  forever. 

5.2.3  The  software  analyst  will  Initiate  a  SHARPS  update  checklist 
(Figure  3).  Upon  completion  of  a  task,  appropriate  personnel 
(e.g.,  SHARPS  developer,  NORDA  technical  analyst)  will  enter: 

•  cognizant  organization  for  task  completion 

•  task  description 

•  date  task  completed 

•  their  initials 

•  comments,  as  necessary 


on  the  Update  Checklist 


Figure  3.  SHARPS  Update  Check  List  (Sample  Form) 


5.2.4  The  update  set  Mill  be  catalogued  it  4  card  leoge  flit  with  lit 
penaanent  flit  nano  SKARPSUPOATImmI  ,  whore  «m1  If  the  SUM  Mt 
tht  eye  It  nunber  tqutls  the  eye  It  softer  of  the  vtnloi  of 
SHARPS  for  which  tht  updttts  ware  developed.  (Note  that  wMIe 
«n  updttt  tot  nay  bt  developed  for  t  port  I  color  SHARPS  cycle.  it 
■ty.  In  ftet .  bo  applied  to  •  It  tor  eye  It). 

5.2.5  Tht  software  analyst  mil  Inspect  tho  update  sot,  ehktog  changes 
where  necessary  to  ensure  that  the  code: 

o  Is  In  agroeMwt  with  SHARPS  propranolol  standards  and  HOC 
update  standards, 

a  does  uhat  It  Is  supposed  to  do, 

e  is  as  efficient  as  possible  while  nootlni  the  two  above 
constraints. 

5.2.6  If  any  changes  are  wade,  a  now  SUN  will  bo  assigned  to  the 
resultant  update  sot.  This  SIM  will  consist  of  the  throe  digits 
of  the  original  SUN  plus  tho  letter  In  tho  alphabet  after  tho 
letter  in  the  old  SUN  (e.g.,  if  the  old  SUN  was  OI«,  tho  mo 
one  will  be  OISE). 

5.3  UPOATE  TESTING 

5.3.1  The  software  analyst  will  apply  tho  update  sot  to  tho  current 
SHARPSNQROAPl  (which  corresponds  to  the  current  ROC  operational 
SHARPS  PL  and  will  create  a  tost  executable  object  code  (180). 
This  executable  code  will  bo  cataloged  with  the  patMwwt  file 


permanent  file  name  and  cycle  number  as  the  test  LGO  except  that 
the  letters  LGO  will  be  replaced  by  the  letters  PL. 

5.3.2  The  test  LGO  will  be  executed  using  the  FACTIVE  and  other  data 
sets,  as  appropriate,  as  Input. 

5.4  QUALITY  CONTROL 

5.4.1  The  software  analyst  will  Inspect  the  outputs,  make  changes  to 
the  update  set  as  necessary,  and  repeat  steps  5.2.5  through 

5.4.1  until  the  outputs  appear  satisfactory. 

If  the  update  set  does  not  Include  any  physics,  mathematics,  or 
modeling  changes,  then  steps  5.4.2  through  5.4.4  may  be  omitted. 

5.4.2  A  listing  of  the  updates,  the  updated  routines,  and  all  test 
output  will  be  transmitted  to  the  principal  SHARPS  developer. 

5.4.3  The  principal  developer,  will  Inspect  the  updates  and  outputs 
and  will  either  approve  them  or  provide  the  software  analyst 
with  a  list  of  recommended  changes. 

5.4.4  The  software  analyst  will  Implement  any  suggested  changes  and 
steps  5.2.5  through  5.4.4  will  be  repeated  until  both  the 
developer  and  software  analyst  are  satisfied. 

5.5  NORDA  TiE 

5.5.1  The  NORDA  configuration  manager  will  be  notified  that  the 
developer  and  the  software  analyst  both  approve  the  current 
update  set.  The  current  SUN,  listings  of  the  updates  and 


updated  routines  and  test  outputs  will  be  provided  to  the  NORDA 
configuration  manager  (or  the  NORDA  technical  analyst)  for  T&E 
at  NORDA. 

5.5.2  The  NORDA  technical  analyst  will  perform  T&E  on  the  update  set 
and  will  either  Inform  the  NORDA  configuration  manager  that  he 
approves  the  update  set  or  he  will  provide  feedback  to  the 
software  analyst  and  principal  developer  and  advise  the  NORDA 
configuration  manager  as  to  the  problems  encountered. 

5.5.3  The  software  analyst  will  Implement  modifications  to  the  update 
set  as  requested  by  the  NORDA  configuration  manager  (as  a  result 
of  NORDA  T&E).  Steps  5.2.5  through  5.5.3  will  be  repeated  until 
the  NORDA  configuration  manager  approves  the  update  set. 

The  procedure  In  steps  5.2.1  through  5.5.3  will  be  performed  for 
each  update  set. 

5.6  COMBINING  UPDATE  SETS 

Update  sets  which  undergo  successful  T&E  and  are  approved  by  the  NORDA 
configuration  manager  in  step  5.5.3  above  will  be  combined  Into  a  single 
update  set  In  preparation  for  the  semiannual  transmission  of  the  update  set 
to  FNOC  for  operational  T&E.  Accordingly,  steps  5.6.1  and  5.6.2  will  be 
performed  semiannually. 

5.6.1  The  software  analyst  will  combine  the  update  sets  Into  a  single 
set,  resolving  update  conflicts  and  making  any  other  changes  as 
are  necessary.  A  new  SUN  will  be  assigned  to  the  resultant 
update  set. 
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5.6.2  Steps  5.3.1  through  5.S.3  art  thtfi  repeated  until  tht  NOROA 
configuration  nanager  approves  tht  caeblned  update  ttt. 

5.7  SOFTWARE  DOCUMENTATION  (SHARPS  UPOATE  REVIEW) 

5.7.1  The  software  analyst  (or  NOROA  Numerical  Modeling  Acoustic 
Applications  Branch)  will  prepare  a  seal  annual  SHARPS  Update 
Review  according  to  the  specifications  In  Section  4.3  above. 

5.7.2  The  SHARPS  Update  Review  will  be  transaltted  to  the  principal 
SHARPS  developer  and  the  NORDA  technical  analyst.  (The  software 
analyst  will  also  receive  a  copy  If  he  was  not  Involved  In  the 
preparation  of  the  docuaent.) 

5.7.3  The  principal  developer  and  the  technical  analyst  (and  the 
software  analyst  when  applicable)  will  review  the  docuaent  and 
will  either  approve  It  or  forward  a  list  of  recoawnded  changes 
to  the  preparer  of  the  docuaent. 

5.7.4  The  docuaent  preparer  will  Incorporate  the  changes  and  steps 
5.7.2  and  5.7.3  will  be  repeated  until  the  SHARPS  developer,  the 
technical  analyst  and  the  software  analyst  are  all  satisfied. 

5.7.5  The  NORDA  configuration  aanager  will  be  notified  that  the  SHARPS 
developer,  the  NORDA  technical  analyst  and  the  SHARPS  software 
analyst  approve  the  Update  Review. 
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lit  titter  cast.  If  «v  dungs  at  til  art  ate  M  tte  update  wt 
delivered  to  FNUC  •  a  am  version  lot  tor  aril  I  te  iftifte  to  tte 
mdlflod  update  sot  telco  rill  tte*  te  ct  to  1  opted  at  RQROA  a  toot 
ultti  tte  corresponding  tost  160  flit. 

5.9.4  upon  cooptation  of  tte  FMX  IK ,  noc  tell  notify  CMC  ate  tte 
NOROA  configuration  oaotpr  of  tte  rtwHi. 

5.9.5  Tte  NOROA  configuration  teteftr  tell  tten  toe  Ida  if  additional 
updates  art  necessary  (and  If  so.  teat  stops  art  to  te  taten), 
or  If  lit  approves  tte  codt  as  it  stands. 

5.9.6  Tte  NOROA  configuration  nanagar  tell  notify  CROC  ttet  te 
approvts  tte  updatt  sot. 

5.9.7  CHOC  tnsurts  ttet  approprlato  configuration  oanagotont 
proetdurts  liavt  boon  follouod  (and  If  SO.  approiti  tte 
Introduction  of  tte  nor  capability  to  operational  status). 

5.10  OPERATIONAL  IMPLEMENTATION 

After  approval  for  operational  Inplatentatlon  Has  Peon  given  by  CROC, 
the  following  stops  tell  be  performed. 

5.10.1  Tte  FNOC  Inplatentatlon  coordinator  all!  transfer  tte  appro  red 
code  to  operational  status  and  permanently  update  all  SHARPS 
relatd  Pi's. 

5.10.1  A  OUMPF  of  ell  SHARPS  related  permanent  files  tell  te  perfected 
for  arcfilvlng  purposes. 
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tit  MM  tavtltftr  mti  t  caff  ttftf  retofasi  if  Mt  aoftotra 
mint. 

I.1U  fit  noc  Mlmmtlta  cttrtlattor  mil  fonaari  a  catlHt 
lmt«9  tf  tit  noc  tptratltoal  H  to  tit  atftotrt  ooaljrtt. 
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oporotieool  ft  list lays,  oof  mil  ptrftro  ttop  U4  to  oatort 
toot  n0C/MMM  ctMittoacj  iat  itaa  oaiatolatd.  If  mg 
tacmUtaaciM  art  fata,  tut  toftotrt  ooaljrtt  mil 
tooBtlottly  aatlfy  tit  noc  lopltoaouttoa  coord  lottor  ood  ut 
MMM  cooflyoratloo  oaooyer  «io  mil  taclta  mot  stops  ora  to 
it  tokaa  to  rtsolvt  tit  lacoosfstoocjr. 

1.114  ffttlo  tot  attfts  tf  tit  opfottt  bocoolay  optratloaol  at  FIX 
oof  MMM*  all  SUMPS  apfoto  enact lists  ora  to  ia  traoamttof 
to  tit  stftotra  ooaljrtt  wio  mil  rttola  a  copy  oaf  forward  the 


orlflMl  to  the  NOROA  configuration  manager.  OOSI  and  NOROA 
•111  each  Maintain  a  SHARPS  update  log  book  containing  the 
checklist  fro*  all  organisations  Involved  In  the  update 

5.12  POfiCNCY  NOCCOUK 

Occasionally,  a  situation  nay  arise  that  nakes  It  Impractical  to  follow 
the  above  procedure  (e.g.a  program  crash  during  a  critical  processing 
period.  Immediate  Fleet  request  for  a  special  format  or  special  processing), 
tfhon  this  Is  the  case,  all  updating  rules  will  be  suspended  and  the  FNOC 
Implementation  coordinator  mill  directly  apply  whatever  updates  are 
necessary.  However,  at  the  earliest  reasonable  moment,  the  FNOC 
Implementation  coordinator  trill  transmit  the  updates  to  the  software  analyst 
who  will  then  recommend  to  the  NOROA  configuration  manager  what  actions  are 
to  be  taken  concerning  these  updates  (e.g.»  delete  them  from  the  FNOC  code, 
put  them  through  the  formal  SHARPS  Update  Procedure,  add  the*  to  an  existing 
update  set  that  will  shortly  be  evaluated,  etc.). 
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